| Oracle TimesTen Replication - TimesTen to TimesTen開発者および管理者ガイド
リリース7.0 E05169-01 |
|
 前へ |
 次へ |
レプリケーション環境の設定に関連する内容は次のとおりです。
既存のデータ・ストアの1つ以上の表をレプリケーションできます。レプリケートする必要があるデータ・ストアが存在しない場合は、まず『Oracle TimesTen In-Memory Databaseオペレーション・ガイド』のTimesTenデータ・ストアの作成に関する説明に従って、そのデータ・ストアを作成する必要があります。
マスター・データ・ストアを指定または作成した後、受信マシンでサブスクライバ・データ・ストアのDSN定義を作成します。マスターおよびサブスクライバのデータ・ストアのDSN属性を設定します（次の「データ・ストア属性」を参照）。
サブスクライバのDSNを設定した後、次の2つの方法のいずれかの方法で、マスターからレプリケートする表をサブスクライバ・データ・ストアに移入できます。
-duplicateユーティリティを使用して、マスター・データ・ストアの内容全体をサブスクライバにコピーします（「サブスクライバへのマスター・データ・ストアのコピー」を参照）。レプリケーション・データ・ストアのDSN定義には、次の属性の設定が必要です。
また、相互にレプリケーションを行うすべてのデータ・ストアで、DatabaseCharacterSet属性が同じである必要があります。TimesTenでは、レプリケート・データ・ストア間のキャラクタ・セット変換は実行されません。
| 注意: | TypeMode属性の設定が異なるデータ・ストア間でもレプリケーションは実行できますが、各レプリケート列の基礎となるデータ型は各ノードで同じにする必要があります。詳細は、『Oracle TimesTen In-Memory Database APIリファレンス・ガイド』のTypeModeに関する説明を参照してください。 |
任意のレプリケーション・スキームでレプリケートする表には、次の特性が必要です。
マスター・データ・ストアを完全にレプリケートするサブスクライバ・データ・ストアに内容を移入する簡単な方法は、マスター・データ・ストアの内容をコピーする方法です。また、障害が発生したデータ・ストアのリカバリ時にも、この方法でデータ・ストアをコピーする必要があります（「データ・ストアのフェイルオーバーおよびリカバリの管理」を参照）。
ttRepAdmin -duplicateユーティリティまたはttRepDuplicateEx C関数を使用して、データ・ストアを複製できます。ただし、マスター・データ・ストアの内容をコピーしてサブスクライバ・データ・ストアに移入する前に、次の手順を実行する必要があります。
たとえば、ホストserver1にはmasterdsデータ・ストアについて記述するmasterDSNという名前のDSNがあり、ホストserver2にはnewstoreデータ・ストアについて記述するnewstoreDSNという名前のDSNがあります。
newstoreデータ・ストアにmasterdsの内容を移入するには、次の手順を実行します。
レプリケーション・スキームを定義し、ttRepStartプロシージャをコールしてレプリケーションを開始するnewrepscheme.sqlという新しいSQLファイルを、テキスト・エディタを使用して作成します。
CREATE REPLICATION repl.repscheme
ELEMENT e TABLE repl.tab
MASTER masterds ON "server1"
SUBSCRIBER newstore ON "server2";
call ttRepStart;
コマンドラインから、レプリケーション・スキームを指定してmasterdsを設定し、レプリケーション・エージェントを起動します。
> ttIsql -f newrepscheme.sql masterds
コマンドラインから、masterdsデータ・ストアの内容をnewstoreデータ・ストアにコピーします。
> ttRepAdmin -dsn newstore -duplicate -from masterds
-host "server1"
これで、newstoreデータ・ストアとmasterdsデータ・ストアの内容が同じになります。
| 注意: | -hostは、リモート・ホストの名前またはTCP/IPアドレスのいずれかで指定できます。TCP/IPアドレスを使用してホストを指定する場合は、-localhostオプションを使用してローカル・ホスト（この例ではserver2）のアドレスを指定する必要があります。詳細は、『Oracle TimesTen In-Memory Database APIリファレンス・ガイド』のttRepAdminに関する説明を参照してください。 |
また、ttRepStartプロシージャおよびttRepDuplicateEx C関数を使用して、前述の処理とほぼ同様のコピー処理をCプログラムからも実行できます。詳細は、「レプリケーション・エージェントの起動および停止」および「障害が発生したデータ・ストアのリカバリ」を参照してください。
トラブルシューティングに関する最新情報は、『Oracle TimesTen In-Memory Databaseトラブルシューティング・プロシージャ・ガイド』のレプリケーションのトラブルシューティングに関する説明を参照してください。
この項の内容は次のとおりです。
TimesTenユーザーに共通に見られる誤解として、ログ・バッファのサイズとトランザクションの消失に関係があるという誤解がありますが、ログ・バッファのサイズは、永続性には影響しません。
DSNがDurableCommits=0で設定されている場合、トランザクションは、次の場合にのみディスクに永続的に書き込まれます。
前述の場合、ログ・バッファのサイズは、TimesTenによるディスクへのデータの書込みに影響しません。
レプリケーション、XLA、Cache Connectまたは増分バックアップを使用しないデータ・ストアでは、アプリケーションでttCkptまたはttCkptBlockingプロシージャをコールするたびに、ログ・バッファ内の不要なレコードおよび不要なログ・ファイルがパージされます。レプリケート・データ・ストアでは、トランザクションがサブスクライバで完全に処理されたことをマスター・レプリケーション・エージェントが確認するまで、トランザクションはログ・バッファおよびログ・ファイルに保持されます（「レプリケーションの動作」を参照）。マスターは、これを確認した時点でのみ、ログ・バッファおよびログ・ファイルからのパージが必要であると認識します。
サブスクライバの状態が変わると、マスター・データ・ストアのログが、レプリケートされていないデータ・ストアのログより大幅に大きくなる可能性があります（サブスクライバの状態については、「サブスクライバのレプリケーション状態の設定」を参照）。サブスクライバがStart状態の場合、マスターはサブスクライバからの受信確認を受信した後、ログされているデータをパージできます。ただし、サブスクライバが使用不能またはPause状態になると、マスター・データ・ストアのログはフラッシュできず、ログに使用する領域が使い果たされる可能性があります。ログ領域を使い果たすと、マスター・データ・ストアでの後続の更新が強制終了されます。
しきい値を設定することができます。この値を超えると、使用可能なログ領域を使い果たす前に、使用不可能なサブスクライバをFailed状態に設定します。
| 注意: | ALTER REPLICATIONを使用して既存のレプリケーション・スキームのしきい値を再設定する場合は、まずレプリケーション・エージェントを停止し、ALTER REPLICATIONを使用して新しいしきい値を設定し、そしてレプリケーション・エージェントを再起動します。 |
デフォルトのしきい値は0（ゼロ）で、「制限なし」を意味します。詳細は、「ディスクベース・ロギングの属性の設定」を参照してください。
マスターは、サブスクライバ・データ・ストアをFailed状態に設定すると、障害が発生したサブスクライバのすべてのデータをログから削除し、そのサブスクライバ・データ・ストアにメッセージを送信します（マスター・レプリケーション・エージェントでサブスクライバ・レプリケーション・エージェントと通信できる場合、メッセージはすぐに送信されます。そうでない場合、メッセージは接続の再開時に送信されます）。サブスクライバは、双方向レプリケーションの場合または他のサブスクライバに更新を伝播するように設定されている場合、マスターからメッセージを受信すると、それ以上更新を送信しません。これは、レプリケーションの点からみて自身の状態が損なわれたためです。
障害が発生したサブスクライバに接続中のアプリケーションは、データ・ストアがレプリケーション・ピアによってFailedとマークされたことを示すtt_ErrReplicationInvalid (8025)警告を受信します。サブスクライバ・データ・ストアにその障害状態が通知されると、マスター・データ・ストアでのその状態はFailedからStopに変更されます。
アプリケーションでは、ODBCのSQLGetInfo関数を使用して、接続中のデータ・ストアがFailed状態に設定されているかどうかを確認できます（「サブスクライバの障害」を参照）。
LogBuffSizeでは、インメモリー・ログ・バッファの最大サイズを指定します。このバッファは、一杯になると、ディスク上のログ・ファイルにフラッシュされます。LogBuffSize値を小さくすると、パフォーマンスに影響はありますが、信頼性には影響しません。
ディスクにロギングを行うときの主な問題は、レプリケーション・ログ・ファイルのために十分なディスク領域を確保することです。ログで使用されるディスク領域の量を管理する場合、次の2つ設定があります。
トランザクションがディスクにロギングされた場合は、ブックマークを使用してサブスクライバにレプリケートされた更新レコードおよびディスクに書き込まれた更新レコードのLSN（ログ順序番号）を検出できます。masterDSNに関連付けられているサブスクライバのブックマークの位置を表示するには、cユーティリティまたはttBookmarkプロシージャを使用します。詳細は、「レプリケート・ログ・レコードの表示」を参照してください。
サブスクライバが停止して、しきい値に達する前に再起動した場合、ブックマークの後に続くログ・ファイル内のコミット済トランザクションが自動的に送信されるため、レプリケーションは自動的にキャッチアップします。ただし、しきい値を超えると、マスターはサブスクライバをFailed状態に設定します。障害が発生したサブスクライバは、ttRepAdmin -duplicateを使用してマスター・データ・ストアをコピーし、処理を最初から再実行します（「データ・ストアのフェイルオーバーおよびリカバリの管理」を参照）。
レプリケーション・スキームには最大128のサブスクライバを含めることができます。アクティブ・スタンバイ・ペアには、最大127の読取り専用サブスクライバを含めることができます。多数のサブスクライバが含まれるレプリケーション・スキームを計画する場合は、次のことを実行する必要があります。
